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Tunneling of SMTP Message Transfer Priorities 
Abstract 
This memo defines a mechanism for tunneling of SMTP (Simple Mail 
Transfer Protocol) Message Transfer Priority values through MTAs 
(Message Transfer Agents) that don’t support the MT-PRIORITY SMTP 
extension. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6758. 


Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The SMTP Message Transfer Priorities extension [RFC6710] specifies a 
mechanism to allow messages to be given a label to indicate 
preferential handling, to enable mail handling nodes to take this 
into account for onward processing. However, as with all SMTP 
extensions, all SMTP Message Transfer Agents (MTAs) between the 
source and the destination must support the extension in order for it 
to be successfully used. This document describes an application- 
layer tunneling of message priority, to convey the priority of the 
messages through MTAs that do not support the Message Transfer 
Priorities extension. The tunneling is done by adding a new message 
header field to the Internet Message Format specified in [RFC5322]. 


A number of other header fields are already in use, mostly in Message 
User Agents (MUAS), to convey meanings related to importance or 
priority of messages. Examples of such header fields are Importance 
[RFC2156], Priority [RFC2156], and X-Priority (undocumented). 
Considering sometimes subtle and sometimes significant differences in 
the meaning of these header fields and widely different syntax, this 
document defines a new header field. 


This document is motivated by 2 main deployment scenarios: (1) an MUA 
talking to a non-MTI-PRIORITY-aware Message Submission Agent (MSA), 
and (2) the use of an unextended MUA to talk to an MT-PRIORITY-aware 
MSA. These 2 use cases are discussed in more detail below. 
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Use case (1) is about an MT-PRIORITY-capable MUA talking to a 
non-MT-PRIORITY-capable MSA [RFC6409], which in turn is talking to an 
MT-PRIORITY-capable MTA [RFC5321]. Both the MSA and MTA are within 
the same ADministrative Management Domain (ADMD) and are on a fast 
network; however, some recipients are accessible via the MTA that is 
talking over a slow link to the next MTA. Communications over that 
slow link can benefit from the use of the MI-PRIORITY SMTP extension. 


In use case (2), a widely deployed client (such as a desktop client) 
is talking to an MT-PRIORITY-capable MSA. The client might be 
extendable via a plug-in API provided by the client developers; 
however, existing APIs frequently allow easy manipulation of email 
header fields, while not allowing for addition of SMTP protocol 
features. In such a case, installing a plug-in on the client that 
can set the MT-Priority header field could provide easier and earlier 
deployment of the MT-PRIORITY SMTP extension in an organization 
without requiring changes to desktop clients. 


We note that the above use cases are not exhaustive and that other 
use cases -- variations of the above -- may exist. The purpose of 
this document is not to consider every scenario, but rather examples 
that reinforce the need to consider a tunneling mechanism that can 
deal with SMTP-capable devices that do not support [RFC6710]. 


2. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119] when they 
appear in ALL CAPS. These words also appear in this document in 
lower case as plain English words, absent their normative meanings. 


The formal syntax uses the Augmented Backus-Naur Form (ABNF) 
[RFC5234] notation, including the core rules defined in Appendix B of 
RFC 5234 [RFC5234]. 


In examples, "C:" and "S:" indicate lines sent by the client and 
server, respectively. Line breaks that do not start with a new "C:" 
or "S:" exist for editorial reasons and are not a part of the 
protocol. 


This document uses the term "priority" specifically in relation to 
the internal treatment of a message by the server. Messages with 
higher priorities may be given expedited handling, and those with 
lower priorities may be handled only as resources become available. 


Melnikov & Carlberg Informational [Page 3] 


RFC 6758 Tunneling of Message Transfer Priorities October 2012 


3. Handling of Messages Received via SMTP 


The subsections of this section update the corresponding subsections 
of Section 4 of [RFC6710]. 


3.1. Handling of the MT-PRIORITY Parameter by the Receiving SMTP Server 


This specification inserts the following between steps 4 and 5 in 
Section 4.1 of [RFC6710]: 


4a. If the sending SMTP client hasn’t specified the MT-PRIORITY 
parameter to the MAIL FROM command, but the message has a single 
syntactically valid MT-Priority header field (see Section 4), 
then the value of this header field is the message priority. 


4b. In the absence of both the MT-PRIORITY MAIL FROM parameter and 
the MT-Priority header field, other message header fields, such 
as Priority [RFC2156] and X-Priority, MAY be used for 
determining the priority under this "Priority Message Handling" 
SMTP extension. Note, however, that the Importance [RFC2156] 
header field MUST NOT be used for determining the priority under 
this "Priority Message Handling" SMTP extension, as it has 
different semantics: the Importance header field is aimed at the 
user recipient and not at the nodes responsible for transferring 
the message. 


3.2. Relay of Messages to Other Conforming SMTP/LMTP Servers 


This specification inserts the following between steps 1 and 2 in 
Section 4.2 of [RFC6710]. 


la. Note that rule 1 also applies to messages that didn’t have any 


priority explicitly specified using the MT-PRIORITY MAIL FROM 
parameter or the MT-Priority header field. 
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3.3. Relay of Messages to Non-Conforming SMTP/LMTP Servers 


This specification appends the following after step 1 in Section 4.3 
of [RFC6710]: 


2. The relaying MTA MUST first remove any and all existing 
MT-Priority header fields from the message. (Please see 
Section 7 for additional considerations related to removal of the 
MT-Priority header field.) 


3. If the incoming message had an MI-PRIORITY parameter specified in 
the MAIL FROM command *or* there was an MT-Priority header field 
removed in step 2 above, then the relaying MTA MUST add its own 
MT-Priority header field with the value determined by the 
procedure in Section 3.1. The syntax of the MT-Priority header 
field is specified in Section 4. 


3.4. Mailing Lists and Aliases 
This specification makes no changes to Section 4.4 of [RFC6710]. 
3.5. Gatewaying a Message into a Foreign Environment 


This specification inserts the following between steps 1 and 2 in 
Section 4.5 of [RFC6710]. 


la. Note that if the destination environment doesn’t support the 
transport of an arbitrary header field, the requirement in 
Section 3.3 to add an MT-Priority header field doesn’t apply. 


3.6. Interaction with the DSN SMTP Extension 
This specification makes no changes to Section 4.6 of [RFC6710]. 
4. Header Field: MT-Priority 
Applicable protocol: mail [RFC5322] 
Status: standard 
Author/change controller: Alexey Melnikov / IESG (iesg@ietf.org) 
on behalf of the IETF 
Specification document(s): RFC 6758 
The MT-Priority header field conveys message transfer priority when 


relaying a message through MTAs that don’t support the MT-PRIORITY 
SMTP extension. 


Melnikov & Carlberg Informational [Page 5] 


RFC 6758 Tunneling of Message Transfer Priorities October 2012 


The ABNF for this header field is defined as follows: 


priority—header-field = "MT-Priority:" 
[CFWS] priority-value [CFWS] CRLF 


where "priority-value" is defined in [RFC6710]. 


Example: 
MT-Priority: -3 


Example: 
MT-Priority: 4 (ultra) 


5. Example 


Note that the following example of an SMTP transaction with 2 
recipients is also making use of the STARTTLS [RFC3207] and Delivery 
Status Notification (DSN) [RFC3461] SMTP extensions, even though 
there is no requirement that these other extensions are to be 
supported when the MT-PRIORITY SMTP extension is implemented. 


S: 220 example.net SMTP server here 

C: EHLO example.com 

S: 250-example.net 

S: 250-DSN 

S: 250-STARTTLS 

S: 250 MT-PRIORITY STANAG4406 

C: STARTTLS 

[...TLS negotiation...] 

C: MAIL FROM:<eljefe@example.com> ENVID=00314159 
MT-PRIORITY=3 

S: 250 <eljefe@example.com> sender ok 

C: RCPT TO:<topbanana@example.net> 

S: 250 <topbanana@example.net> recipient ok 

C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS, FAILURE 
ORCPT=rfc822;Dana@Ivory.example.net 

S: 250 <Dana@Ivory.example.net> recipient ok 

C: DATA 

S: 354 okay, send message 

Cs (message goes here) 

Cri 

S: 250 message accepted 

C: QUIT 

S: 221 goodbye 


Here, the receiving SMTP server supports the "STANAG4406" Priority 
Assignment Policy [RFC6710] with 6 priority levels, so it will use 
the priority value 4 internally (the next supported priority higher 
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6. 


or equal to 3) and will communicate the priority value 3 when 
relaying it to the next hop (if necessary). When relaying the 
message to the next hop that doesn’t support the MT-PRIORITY SMTP 
extension, the transaction might look like this: 


S: 220 example.org SMTP server here 

C: EHLO example.net 

S: 250-example.org 

S: 250-DSN 

S: 250-STARTTLS 

S: 250 SIZE 

C: STARTTLS 

[...TLS negotiation...] 

C: MAIL FROM:<eljefe@example.com> ENVID=00314159 

S: 250 <eljefe@example.com> sender ok 

C: RCPT TO:<topbanana@example.net> 

S: 250 <topbanana@example.net> recipient ok 

C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS, FAILURE 
ORCPT=rfc822;Dana@Ivory.example.net 

S: 250 <Dana@Ivory.example.net> recipient ok 

C: DATA 

S: 354 okay, send message 

C: MT-Priority: 3 

Cx (the rest of the message goes here) 

Cx cx 

S: 250 message accepted 

C? QUIT 

S: 221 goodbye 


IANA Considerations 


IANA has added the following list of header field names to the 
"Permanent Message Header Field Names" registry (in 
<http://www.iana.org/assignments/message-headers/perm—-headers.html>): 


Header field: MT-Priority 

Applicable protocol: mail 

Status: standard 

Author/change controller: Alexey Melnikov / IESG (iesg@ietf.org) 
on behalf of the IETF 

Specification document(s): RFC 6758 


Security Considerations 


This document allows a message priority to be tunneled through MTAs 
that don’t support the MI-PRIORITY SMTP extension by specifying how 
it can be represented in the message itself (using the MT-Priority 
header field). Thus, it is important to ensure that an MTA receiving 
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a message containing the MT-Priority header field can trust that it 
was set by an authorized agent. The use of technologies such as 
Domainkeys Identified Mail (DKIM) [RFC6376] or S/MIME to sign the 
MT-Priority header field value can enable a recipient to verify 
whether the specified priority value was generated by a trusted 
agent. In particular, DKIM signing allows a recipient to verify that 
the specified priority value was present when the message was signed, 
and to verify who signed the message. Note, however, that the DKIM 
signer might not be the same agent that generated the MT-Priority 
header field. 


MSAs ought to only accept message transfer priorities (whether by 
using the MI-PRIORITY parameter to the MAIL FROM command or the 
MT-Priority header field in the message itself) from users (or only 
certain groups of such users) who are authenticated and authorized in 
some way that’s acceptable to the MSA. As part of this policy, they 
can also restrict maximum priority values that different groups of 
users can request and can override the priority values specified by 
MUAs. When relaying to non-MT-PRIORITY-capable SMTP/LMTP (Local Mail 
Transfer Protocol) servers, such MSAs are required to replace any 
MT-Priority header field values that don’t satisfy this policy. See 
Section 7.1 for more details on what the consequences of such changes 
might be. 


Similarly, MTAs ought to only accept message transfer priorities 
(whether by using the MI-PRIORITY parameter to the MAIL FROM command 
or the MT-Priority header field in the message itself) from senders 
(or only certain groups of such senders) who are authenticated and 
authorized in some way that’s acceptable to the MTA. As part of this 
policy, they can also restrict maximum priority values that different 
groups of senders can request and can override the priority values 
specified by them. When relaying to non-MT-PRIORITY-capable SMTP/ 
LMTP servers, such MTAs are required to replace any MT-Priority 
header field values that don’t satisfy this policy. See Section 7.1 
for more details on what the consequences of such changes might be. 


In the absence of the policy enforcement mentioned above, an SMTP 
server (whether an MSA or an MTA) implementing the MT-PRIORITY SMTP 
extension might be susceptible to a denial-of-service attack. For 
example, malicious clients (MUAs/MSAs/MTAs) can try to abuse this 
feature by always requesting priority 9. 


To protect the MT-Priority header field from modification or 
insertion, MUAs, MSAs, and MTAs inserting it into messages SHOULD use 
a message header protection mechanism such as DKIM [RFC6376]; 
however, see Section 7.1 for more information. 
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7.1. Modification of the MT-Priority Header Field and DKIM 


An MSA/MTA that receives a message with an MT-Priority header field 
protected by DKIM and that wants to change the message priority due 
to its policy is forced to choose between 


a. breaking DKIM signatures (by replacing the MT-Priority header 
value), 


b. leaving the message as is (and using the MT-PRIORITY MAIL FROM 
parameter), relying on the fact that all downstream MTAs are 
compliant with this specification, and 

c. rejecting the message. 

None of these choices are perfect. They work in a particular 

situation, so these choices should be carefully considered during 


implementation and deployment. 


If the MSA/MTA decides to alter the message, it SHOULD re-sign the 
message with DKIM. 
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